NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/4821

Internet Message Format | 1996-08-05 | 5.7 KB

Path: informatik.tu-muenchen.de!fischerj
From: [e-mail] (Juergen "Rally" Fischer)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: doubling pixels horizontally
Date: 5 Mar 1996 14:38:55 GMT
Organization: Technische Universitaet Muenchen, Germany
Distribution: world
Message-ID: <4hhjlv$[e-mail]>
References: <4f4ibc$[e-mail]> <[e-mail]><[e-mail]><4faoe1$[e-mail]><[e-mail]><[e-mail]><[e-mail]>   <[e-mail]> <4gbjg3$[e-mail]>  <[e-mail]> <4h4hv5$[e-mail]> <[e-mail]>
NNTP-Posting-Host: hphalle6g.informatik.tu-muenchen.de
Originator: [e-mail]


In article <[e-mail]>, [e-mail] (Ludvig Pedersen) writes:
|> Organization: Dept. of Informatics, University of Oslo, Norway
|> Lines: 70
|> Message-ID: <[e-mail]>
|> References: <4f4ibc$[e-mail]> <[e-mail]><[e-mail]><4faoe1$[e-mail]><[e-mail]><[e-mail]><1257.6614T57T922|> @vip.cybercity.dk>
|>      <[e-mail]> <4gbjg3$[e-mail]>
|>     <[e-mail]> <4h4hv5$[e-mail]>
|> NNTP-Posting-Host: gymir.ifi.uio.no
|> X-Newsreader: THOR 2.22 (Amiga;TCP/IP)
|>
|> >Maybe I'm the only one but I can read/build code much better that way.
|> >And I could read my code well :)
|>
|> WOW!...do you have any super-natural powers? ;^)

grrrrrrrrrrrrrrr :) no that's just a subjective thing.

Code gets more structured (grrr don't laugh ;) and though more overview.
Puting instructions next to each other which are related to each other

subq.w #1,a5 : cmp.w #0,a5 : bne loop ;out of data registers

just one structure level more, code gets 2 dimensional (blah:) like
in C code. And as asm needs more instructions than C, it needs the
2 dimensional format even more if you don't wanna lose overwiev. baeh!
:)

|>
|> >|> >I would be happy if we could get a 3pass almost at copy speed.
|> >|> >(well copy speed, that's 7mb/sec on 030 ? or are we refering to
|> >|> >the 4mb/sec on 020-14 ?)
|> >|> On my A1200 7mb/sec is not copy speed but chip write speed.
|> >mhm, all people told me the blizzard will _copy_ 7mb/sec.
|> >a myth ?
|>
|> I think so. But please show me the copy-loop and I'll test it.

could you please try movem.l (fast)+,d0-d7 and then 8 times move.l dn,(chip)+ ?

imho this should do 7mb/sec in the store part. if the movem
is very fast, you aproximate the 7mb/sec also doing copying.

On 020-14 it will be slower than normal copy, on 020-28 maybe already
faster (only theory!)

so we still need a test if it's faster than move.l (fast)+,(chip)+

|>
|> BTW:
|>
|> The Blizzard can WRITE 7 MB/s to chipram.
|>
|> Here is my results from bustest:
|>
|> BusSpeedTest 0.07 (mlelstv) Buffer:    16384 Bytes
|> ==================================================
|> loop overhead:      4.5ns
|> register move:     40.6ns

huh ? a register move is 2 cycles. you got 24.63 MHz ?

|> memtype   op      cycle      bandwidth
|> fast      readw   109.1ns   18.3MByte/s
|> fast      readl   137.6ns   29.1MByte/s
|> fast      readm   167.7ns   23.8MByte/s

readm slower ? hmhmhmhm. nooo.
if you use enough regs it's faster on 020-14.
also reading from chip is faster with readm... mhmhm

|> fast      writew  120.2ns   16.6MByte/s
|> fast      writel  120.7ns   33.1MByte/s
|> fast      writem  109.9ns   36.4MByte/s
|> chip      readw   589.9ns    3.4MByte/s
|> chip      readl   590.3ns    6.8MByte/s
|> chip      readm   640.5ns    6.2MByte/s
|> chip      writew  572.9ns    3.5MByte/s
|> chip      writel  573.6ns    7.0MByte/s
|> chip      writem  573.3ns    7.0MByte/s
|> rom       readw   109.0ns   18.3MByte/s
|> rom       readl   137.6ns   29.1MByte/s
|> rom       readm   167.3ns   23.9MByte/s
|>
|> Please not that this is write-speed and NOT copy speed.
|>
|> >|> I did a simple test and I was able to copy 4.9mb/sec from fastram to
|> >|> chipram on a 256 colors screen.
|> >what size ?  overscan, 320x256,320x200 ? pal ?
|>
|> PAL-lowres, no overscan.

maybe you can write in 10 14-mhz cycle parts, i.e 5.672mb/sec theoretic
if no dma at all.

|>
|> >|> I don't get it??? ;) It is optimal. That was actually VERY easy. Remeber
|> >|> that we are taking about 2x2 without sprite-dithering!!
|> >either you misuse a plane as mask, so 128 colors only, or the 2x2
|> >routine is slower than 3pass, i.e. not optimal :)
|>
|> The blitter uses only 2 passes and *is* optimal. And its 256 colors.
|>
hehe, 2 passes blitter is slower than 1 pass blitter ;)
there's a misunderstanding in the word "optimal".
while there realy might be no way to do faster the way you do,
there's another way to do it :) the other way has disadvantages
(monitor sideefects ;) though.

|> >|> >I currently got problems with my way of calling qblit. You got a demo
|> >|> >executable ? Mine locks up with small OS-blits :\
|> >|> I don't have that problem. You can look at the source. It will be released
|> >didn't test it yet, but seems that peter found the bug:
|> >I busywait for qblit ready (normaly it is ready).
|> >So another lower pri task can't disown blitter.
|>
|> Yes, I know.
|>
|>
|> <sb>Ludde - Amiga Demo Coder
|> <sb>Virtual Reality & Official Be developer
|> <sb>[e-mail]
|>
------------------------------------------------------------------------
   [e-mail] (Juergen "Rally" Fischer)   =:)